昨天，我們替部門內的 AI 流程留下了食譜，也讓備援夥伴實際接手。原作者終於可以安心休假，工具也開始成為團隊共同照看的資產。

但當自己的工作跑得更順，另一種卡頓，往往才真正浮現。

試想，一位負責彙整資料的夥伴來找我：

「我們整理文件已經很快了，可是前一個窗口有時傳截圖，有時把重要資訊寫在備註裡。整理完，下一個團隊又要我們填回另一張 Excel，連顏色都得重標。」

他攤開雙手：

「我們好像只是更快地，跑到下一個塞車點而已。」

這句話，道出了工作流程中最常見的局限：單一步驟的孤立加速，未必能縮短整體交付；產出增加了，反而可能讓下游積壓更多等待處理的工作。各部門若只是各自裝上一台更快的發電機，孤島之間的海峽依然存在。

工作坊落地的下一步，就是沿著資料的去向，推開隔壁團隊的門。

一、先喝杯咖啡，把「已完成」的意思說清楚

跨部門接軌，可以從每天都讓雙方疲憊的補件開始聊。

「我們想減少來回確認。能不能先把項目代號、更新日期和處理狀態固定下來？我們提供範本，你們也不用每次重新整理。」

對方可能反問：「已完成，是指我們處理好了，還是已經有人確認？」

很好，真正需要對齊的地方出現了。

同樣叫「完成」，一邊指的是資料已送出，另一邊理解成內容已確認；同樣叫「截止日」，有人填預計日期，有人填最後期限。格式再漂亮，也可能只是把誤會裝進整齊的盒子裡。

這就是「資料契約（Data Contract）」的起點：雙方對資料的結構、意義、品質與交付責任，建立起白紙黑字的共同約定。

小型流程可以先約定四件事：

交什麼： 必要欄位、格式，以及資料代表的工作意義。

怎麼算合格： 必填項目、允許值，以及重複資料的處理方式。

何時、交到哪裡： 交付頻率，以及核准的共享位置。

出問題找誰： 補件窗口，以及欄位或定義變更時的通知機制。

雙方可以保留各自習慣的工作方法，但在交接的接觸面上，必須有共同的依據。

部門牆最先鬆動的地方，往往就是那一句：「原來你說的完成，跟我理解的不一樣。」

二、替不同的語言裝上轉接頭

約定有了，接下來才輪到工具上場。

例如，一個團隊每天留下專案進度紀錄，內容包含已處理事項、待辦項目與需要協助的問題。AI 可以協助從文字中擷取候選資訊，再依雙方確認的欄位整理。

試點時，可以先用固定標籤的清單，讓雙方肉眼看得懂；持續自動交換時，再依工具需求採用有明確規格的 CSV 或既有範本。Markdown 適合閱讀，卻不會因為看起來整齊，就自動成為可靠的資料介面。

還要讓每筆資料能回到原始紀錄：這個日期從哪裡來？這項工作是已經完成，還是預計完成？如果原文含糊，就標記待確認，不能讓下一個 AI 接著猜。

自然語言能幫助人把需求說清楚，AI 也能協助處理不同表達方式；但它仍可能誤讀，或補出看似合理卻不存在的內容，這些都需要檢查與驗證。

架構可以先從這條路開始：

原始紀錄 → AI 協助擷取 → 欄位與來源檢查 → 合格資料交付 → 下游處理與驗收

對固定欄位、日期檢查與明確規則，優先使用可重複驗證的程式；需要理解文字脈絡的部分，再讓 AI 協助。

小型試點透過核准的檔案交付就能先走通，先從簡單容易產生共識的開始。隨著頻率、規模與重要性提高，再回頭評估正式介面、監控與維護方式。這條連通管，可以先細，再逐步加固。

三、讓下游接得住，比展示速度更有說服力

前一段接好了，下一個團隊那張熟悉的 Excel 還在等你。

先問問看：欄位排序為什麼固定？黃色代表缺件，還是待確認？公式是否連著其他文件？

你可能發現，那張看似笨重的表，承載著另一個團隊多年累積的工作規則與責任劃分。

這時，可以借用系統整合的轉接思維，在自己的邊界建立相容產出。

用經過驗證的程式，把整理好的資料填進既有範本，保留必要欄位、公式與格式；如果儲存格的顏色代表「已確認」，就要尊重背後的責任分工，不能因為資料填完了，就自行替確認窗口畫上記號。

AI 可以協助寫程式初稿，成品仍要用測試資料核對，再請接收方確認。

某天，接收資料的同事打開檔案，發現熟悉的欄位都在，資料來源查得到，缺漏也被清楚標記，少了幾次來回詢問。

他可能抬頭問：

「你們最近怎麼整理的？這次比較好核對耶。」

那就是一扇門開始打開的聲音。跨部門的信任，會在一份份接得住、查得清的交付裡，慢慢累積。

四、IT 架構師，替連通管規劃河道

當團隊開始搭建這些小管道，IT 的工作也有了新的重心。

如果你把它想成水利工程：各個工作窗口最熟悉沿岸農田的需求，IT 則協助規劃河道，必要時一起設計與施工。

先看水質： 資料跨部門流動，接觸面也會擴大。相關資料負責人與對接窗口，要一起確認用途、存取權限及可使用的工具。

再看水量： 工具配額、處理量、失敗重試與通知機制，都會影響這條管道能承接多少工作。

最後看維護： 欄位規格與版本放在哪裡？誰負責變更？哪一段失敗可以被發現？出了問題，如何退回既有流程？

IT 可以提供外部建議，讓同仁少走冤枉路。涉及正式系統、敏感資料或重要決策時，相應的管理機制也要跟上。

使用者把業務需求說清楚，流程中涉及的夥伴協同把運作條件補齊，這些管道才有機會長期流通。

從一條管道，走向一張光網
先挑一份文件、一類需求，或一個交接步驟試跑。

觀察整體交付有沒有提早、補件是否減少，也把覆核與維護時間算進去。成果站得住，就邀請上下游一起看操作方式、失敗案例與處理方法。

每次合作，都多留下一點共同語言。

資料提供者知道少一個欄位會在哪裡卡住；彙整夥伴理解前一段的紀錄方式；確認窗口開始把隱性規則說明白。大家終於能沿著同一條流程，心平氣和地討論哪裡值得改善。

退後一步看，那些原本分散在不同工作崗位的種子成員，透過文件、資料約定與日常交付，逐漸連成一張若隱若現的光網。

這張網會長得多快，還取決於工具可靠性、制度支持與合作意願，沒有一個比例能替所有組織保證結果。

但故事已經走到值得追問的地方：當少數人的能力開始彼此連接，改變能不能越過部門邊界，成為更多人的日常？

明天 Day 30，我們將從組織網絡與創新擴散的角度，探索這些種子如何帶動更廣泛的採用，以及「臨界比例」需要哪些條件才能成立。